Skip to main content

Grupo 8 - Infantem

En esta página se encuentra el feedback recogido por el equipo del grupo 8 durante las sesiones de clase. Con secciones para cada semana, se detallan los comentarios y sugerencias del profesor y los compañeros, así como las tareas a realizar para la siguiente semana. Además, se incluye una sección para cada grupo con el feedback proporcionado por el grupo 8.

Semana 10/02​

Feedback relacionado con la presentación​

  • Buscar logotipo (imagen + letra) y ponerlo en todas las diapositivas, que quede claro lo que estamos vendiendo.
  • Buscar formas de transmitir el objetivo lo más compacta posible, un eslogan muy resumido.
  • Centrarnos en la parte más relevante. Proyecto quizás demasiado grande, mejor menos cantidad pero de mayor calidad. Tiene que tener un alcance realista.
  • Análisis de competidores: muchas de las amenazas vienen de la competencia (cambiar el orden en las diapositivas para que vaya justo después del DAFO)
  • Mirar lienzo de modelo de negocios.
  • Riesgo con el tema de las apis, tener definido un acuerdo con un proveedor de servicios.
    • Básicamente mirar bien todo el DAFO.
    • Mala idea poner la descripción del equipo tras la portada, mejor centrarse directamente en la idea de negocio.
  • Primero mencionar qué problema se resuelve antes de introducir el pago
  • Durante las presentaciones decir solo lo útil, de otra forma se pierde tiempo y la atención de los oyentes
  • Presentarnos al principio

Feedback relacionado con el desarrollo del proyecto​

  • Centrarnos en un elemento diferenciador de nuestra idea.
    • Mirar que el elemento diferenciador sea posible, tanto por accesibilidad a recursos y por capacidad técnica.
    • Revisar si hay alguna característica que no tiene ninguno de los competidores.
  • Mirar si hay partes que se pueden aislar. Ej: poder usar la parte de gestión de finanzas para eventos pequeños.
  • Modelo de monetización demasiado amplio, mejor centrarnos en uno (de esta parte no me he enterado bien)
  • Segmento de mercado: usar protopersonas (usuario potencial de nuestra aplicación, que tenga el perfil definido).
    • Definir personas, estamos mezclando personas con grupos.
  • Casos de uso: mirar bien la trazabilidad
    • Mirar que casos de usos que no son estrictamente necesarios (MVP) y centrarnos en esos.

Semana 17/02​

Feedback relacionado con la presentación​

  • Mucho texto en diapositivas
  • En los mockups no se ponen lorem ipsum ni datos vacíos, siempre casos reales.
  • Mirar una página: getmanfred.com, en esa página hay muchos datos sobre sueldos respecto a años de experiencias, tecnologías…
    • Mirar también comparación con quien sabe inglés y quien no (esto es más como curiosidad)
  • Hemos tardado mucho en llegar a los competidores, esto mejor hacerlo después de las características.
  • Presentación un tanto corta, sobre todo si es la primera vez que hablamos de la idea
  • Nos faltan muchas cosas en las presentaciones.

Feedback relacionado con el desarrollo del proyecto​

  • No se tiene claro cómo se monetiza. El tema de pagar pediatras no está claro.
    • Se habla de gastos, pero no de ingresos.
  • No se ponen las funcionalidades de pagos. Si solo son conexiones con pediatras hay muchos seguros privados que ya lo ofrecen, por lo que es improbable que la gente lo utilice.
  • El problema que se plantea no es real puesto que ya en los hospitales las marcas se promocionan.
    • De igual forma, se podría enfocar justo con las promociones con las marcas para intentar explotarlo en la aplicación
  • Hay que madurar esta idea muchísimo.
    • Si hay competencia mirar como lo hacen ellos, como cobran, cual es su modelo de negocio…
    • Mirar varios percentiles: peso, tamaño de cabeza…
  • Costes: de dónde han salido las cifras?
    • En el costes hay que tener en cuenta los impuestos y contribuciones sociales.
  • ¿Quién hace las dietas personalizadas?
    • Pega más nutricionista que un médico
    • Hay que tener en cuenta los sueldos de los nutricionistas
  • Seguramente otras entidades hagan mejor nuestra funcionalidad que nosotros.
  • ¿Dónde está la principal diferencia con los competidores?
  • Privacidad importante.

Semana 24/02​

Feedback relacionado con la presentación​

  • No hay diferencia entre MVP y producto. No se ha especificado que es el producto.
  • No mencionamos de dónde hemos sacado los competidores ni qué hacen.
  • La presentación debe ser autocontenida:
    • No se puede depender de cosas mencionadas anteriormente ni cosas que ha mencionado ningún otro grupo.
  • Poner los riesgos al final, tras analizar todo lo relacionado con la idea del negocio.
  • Leyenda puesta en la parte de Competidores y no se usa.
  • Cambiar la tipografía de la presentación, utilizar una más legible.
  • En la presentación hablamos de ingresos no de beneficios, estas diapositivas “no son legibles” .
  • Siempre se trabaja sin IVA, incluir el plan de precios y explicar en qué consiste.
  • No se ha mencionado el coste del plan premium aunque esté en la presentación
  • Redondear a dos decimales o directamente a las unidades
  • Enfocar la presentación a un público técnico
  • Incluir todo lo que hay que presentar en la presentación.
    • El principal problema ha sido desarrollar demasiado algunos puntos de forma que se han comido todo el tiempo, haciendo que eliminemos puntos necesarios. Es mejor comentar todo de forma resumida con solo los puntos importantes que explicar a fondo dos puntos.

Feedback relacionado con el desarrollo del proyecto​

  • Hemos incluido características que no pertenecen al MVP.
  • Métricas cuantitativas para el control y seguimiento.
    • Cuidado al poner normas basadas en estas métricas (la gente suele obsesionarse con ellas y es lo que priorizan haciendo trampas muchas veces)

Semana 03/03​

Feedback relacionado con la presentación​

  • Ha pasado el Business Model Canvas muy rápido, si no vamos a enseñar algo en condiciones mejor no ponerlo.
  • Demasiado detalle de los costes
  • No hemos hecho mención a la rama develop

Feedback relacionado con el desarrollo del proyecto​

  • No tiene sentido asignar a los usuarios pilotos perfiles. Deberíamos buscar padres reales.
  • No incluir puntos que no tocan en la presentación aunque en la semana anterior no se haya presentado.
  • El stack tecnológico no se pedía.
  • Ignorar decimales. Además, desde lo lejos no se logra distinguir el punto de miles de la coma de decimales.
  • Especificar los costes en una tabla y sumar todos (hacer más digerible la información). Cuidar la distribución de la información.
  • Reducir la información, centrarnos en lo importante.
  • No se ve el símbolo de porcentaje en los costes (fuente de letra muy fina).
  • Mejor poner el gráfico de la evolución de las ganancias cada mes.
  • La parte de planificación no se ve bien, nada legible. Hacer énfasis en el diagrama de Gantt
  • Ser más descriptivo en la planificación: no usar siglas cuyo significado no sea obvio.

Semana 10/03​

Feedback relacionado con la presentación​

  • Si tenemos que hacer demo/enseñar video:
    • Asegurarnos de que se vea todo.
    • No enseñar el login/register.
    • Contar una historia: Humanizar la experiencia, usar una persona real para que todo tenga un hilo argumental.
    • Recetas y usuarios realistas, no enseñar receta1, receta2 .. user1.. etc.
    • SOLO ENSEÑAR Y DARLE IMPORTANCIA A LO CORE.
  • Tener un mejor killer opener (QUE VUELVA EL BEBE), muy neutro hay que llamar más la atención .
  • Tardar menos tiempo en explicar el proyecto (hemos tardado 3.50).
  • Los bebés de la presentación están bien pero quizás sobran algunos que no dicen nada del epígrafe.
  • Las X de los competidores que sean rojas para que impacte más.
  • Seguir analizando la estructura jerárquica del equipo (Mejor hablar de responsabilidades que de roles).
  • El feedback tenemos que seguir priorizando.
  • Buscar más usuarios piloto.
  • Super importante mostrar algún prompt como el de las dos últimas presentaciones (caronte o map Your World).
  • Falta explicar cómo hemos calculado las notas.

Feedback relacionado con el desarrollo del proyecto​

  • Poner datos de prueba realistas, no receta 1 receta 2, user1 user2.
  • No estamos usando sonar ni herramientas para comprobar el código que haya que refactorizar (podemos analizar la evolución de las métricas de sonar a lo largo de los siguiente sprints).
  • Analizar cuando “alucinan” las IAs que estamos usando y marcarlo en el documento de prompts para cuando se haga el análisis.

Semana 17/03​

Feedback relacionado con la presentación​

  • Hacer que el inicio efectivo sea aún más impactante y conectarlo con la demo y otras partes de la presentación para "cerrar el círculo".
  • No referirse a los inversores en tercera persona, sino hablarles directamente.
  • Mejorar el killer opener y asegurarse de que esté bien integrado con el final.
  • La demo combina el estado actual con lo que se tendrá en el futuro, pero está bien presentada.
  • Indicar claramente qué herramientas de IA se utilizan y presentar casos de uso reales.
  • Reemplazar "papás primerizos" por "padres".
  • Copiarle la gráfica de rendimiento a caronte
  • Impacto legal, menos texto y quedarse con lo más importante
  • INICIO EFECTIVO Y mejorar presentación. Mejorar el killer opener, hilar con la demo y el final, importante "cerrar el círculo".
  • Asegurar que las fotos del equipo sean homogéneas.

Feedback relacionado con el desarrollo del proyecto​

  • En el storyboard dirigido a inversores, no hablar de la persona usuaria, sino centrarse en los beneficios que pueden obtener los inversores.
  • Al presentar cifras, destacar el rendimiento y datos atractivos para incentivar el pago.
  • Justificar la parte premium con un enfoque claro: la personalización de recetas y dietas a medida.
  • Incluir un coste extra para posibles revisiones de los planes de nutrición.
  • Ajustar mejor la estrategia de negocio, asegurando que los pagos de los clientes sean viables y sostenibles.
  • Incorporar métricas clave como TAC (coste de adquisición de clientes) y LGV (lifetime value) para analizar hasta qué punto es rentable seguir adquiriendo clientes.
  • No hacer que el producto aparezca "mágicamente" en el storyboard. Se recomienda involucrar a terceros, como que alguien lo descubra en la farmacia o en otro contexto realista.
  • Agregar una tabla con escenarios pesimista, realista y optimista en una misma diapositiva, asegurando que las cifras estén correctamente formateadas con puntos en los miles.
  • No hacer que el producto aparezca "mágicamente" en el storyboard. Se recomienda involucrar a terceros, como que alguien lo descubra en la farmacia o en otro contexto realista.
  • Mantener coherencia en la historia, llevando al personaje principal (ej. Laura) desde el inicio hasta el final de la presentación.
  • Agrupar las gráficas de costes en una sola diapositiva para mejorar la claridad.
  • Utilizar fotos homogéneas en el equipo (IMPORTANTE).
  • El rendimiento individual del equipo debe mostrarse de forma más visual, con barras de horas por persona.
  • Incluir métricas de impacto legal con menos texto y solo la información clave.
  • No incluir información innecesaria o en lugares donde no corresponda.
  • Mejorar la cobertura de testing, actualmente en 0%. Es fundamental incluir pruebas.
  • Incluir planes de refactorización y detallar qué patrones de diseño se van a implementar.
  • La última diapositiva contiene una URL antigua del despliegue; actualizarla.
  • El informe de métricas es excelente y destaca sobre los otros grupos. Sin embargo, no es necesario incluir archivos específicos solo para el equipo interno.

Semana 24/03​

Feedback relacionado con la presentación​

  • En general, muchas cosas se han hecho muy bien. La presentación fue extensa pero bien ejecutada.
  • Killer opener muy efectivo y bien conectado con la demo.
  • Para reforzar la conexión con la demo, sería bueno incluir una foto del compañero que está usando la aplicación.
  • En algunos puntos, hay demasiado texto en las diapositivas y pocas metáforas visuales. Se recomienda invertir esta relación: usar más imágenes y metáforas, y que el texto sirva solo como apoyo. Esto es especialmente importante en el Customer Agreement y en la - retrospectiva.
  • No leer directamente las diapositivas, sino utilizarlas como guía visual.
  • Presentador debería intentar variar más el tono de voz para evitar un discurso monótono.

Feedback relacionado con el desarrollo del proyecto​

  • El storyboard del cliente está muy bien elaborado.
  • El storyboard de inversores necesita mejoras: es recomendable resumir los números y evitar incluir céntimos.
  • La priorización del feedback de los usuarios piloto ha gustado mucho y ha sido clara.
  • Sin embargo, podría reorganizarse o reconsiderarse si es necesario mencionar el MVP en ese punto, ya que puede sobrar en la presentación.
  • Se recomienda desgranar la información de SonarQube para identificar con precisión los márgenes de mejora. Es importante hablar en términos generales y también destacar la progresión de las métricas más relevantes.
  • La gráfica de costes necesita un cambio en el título, ya que no refleja únicamente costes.

Semana 31/03​

Feedback relacionado con la presentación​

  • David ha mejorado la modulación de la voz respecto a la vez anterior, pero aún puede mejorar jugando más con los tiempos y las pausas. Recordar que en presentación oral, las comas no existen y los puntos se convierten en comas para mantener fluidez.
  • El killer opener fue efectivo, pero sería más potente si estuviera mejor conectado con el problema real que resuelve el proyecto. - La frase “parece que está malo el chaval” remite a un tema de salud, por lo que habría que enlazarlo más con la dimensión de salud, no solo alimentación.
  • El anuncio es un muy buen primer intento, pero debe ser autónomo y comprensible por sí solo, no depender del storyboard para entenderlo.
  • Es importante acortar aún más el contenido general, especialmente la parte del MVP, que actualmente es extensa.
  • El sistema de priorización y categorización de feedback de usuarios piloto ha sido muy bien valorado, aunque podría reorganizarse para mejorar la claridad.
  • La diapositiva de horas debería mostrar el número total de horas trabajadas, no solo la distribución.
  • Se valoró positivamente la idea de hablar de la experiencia de usuario basada en los usuarios piloto. Hay que desarrollarlo un poco más.
  • En el gráfico de SonarQube, se debe explicar qué significa la letra E, para que no quede ambigua.
  • La parte de inteligencia artificial no llegó a explicarse. Si no se puede abordar en el tiempo disponible, es mejor recortar el MVP y enfocarse en lo esencial

Feedback relacionado con el desarrollo del proyecto​

  • En la demo, se deben incluir fotos reales de las recetas. El uso de texto tipo lorem ipsum en ese contexto no es aceptable.
  • Es fundamental explicar claramente cómo se personalizan las recetas y cómo se realiza el proceso de matching con el usuario. Este aspecto debe abordarse en futuras explicaciones del producto.
  • Para mostrar la evolución del proyecto, no basta con listar mejoras basadas en usuarios piloto. Sería útil montar un sistema como Grafana, que permita automatizar la detección y visualización de mejoras de forma más técnica y continua.
  • El enfoque del marketplace debe revisarse para evitar problemas al redirigir a páginas externas, lo que podría comprometer la experiencia del usuario.
  • En el tema de inversión, sería más realista buscar pequeños inversores con aportaciones menores, en lugar de depender de un único gran inversor. Inversiones típicas rondan los 50k a cambio de un porcentaje, con expectativas de retorno de x20 o un 30% anualizado. Estas cifras no deben mostrarse literalmente, sino reflejarse a través de proyecciones trabajadas.
  • El manual de marca debe complementarse añadiendo el slogan y desarrollando un poco más el contenido visual e identidad.

Semana 07/04​

Feedback sobre la presentación​

  • David ha mejorado su forma de presentar, aunque a veces solapa frases o abarca demasiado contenido. Se recomienda reducir el alcance de algunas secciones.
  • Se sugiere incluir más metáforas visuales y reducir la cantidad de texto en las diapositivas.
  • El killer opener está mucho mejor alineado con la temática del proyecto.
  • El anuncio de freemium y premium debería unificarse en una sola pieza para mayor claridad.
  • Aunque el análisis del rendimiento y del plan de contingencia fue muy sólido, algunas diapositivas contenían demasiado texto.

Feedback sobre el proyecto​

  • En el vídeo de inversores, es necesario incluir las fuentes de los datos además de las cifras, que por cierto, se pueden abreviar (ej. “1k” en lugar de “1.000”).
  • Adaptar la estrategia de marketing considerando que la edad media de los padres primerizos ha aumentado. Justificar el enfoque hacia distintos segmentos del mercado.
  • Las métricas sobre bebés provienen de la OMS, pero convendría adaptarlas al contexto local.
  • Se debe clarificar el código duplicado diferenciando claramente entre frontend y backend.
  • Las métricas de Sonar deben interpretarse (algunas son buenas si suben, otras si bajan); usar metáforas o separarlas visualmente para facilitar su comprensión.
  • Buen trabajo priorizando el feedback del usuario piloto, aunque se recomienda reforzar el apoyo visual en esa sección.
  • El análisis de amenazas fue adecuado, pero el título debería ser más específico. Ej.: “Amenazas críticas del sistema”.
  • Las métricas usadas para calcular el diferencial de notas son poco informativas actualmente; hay que detallarlas mejor.

Semana 21/04​

Feedback sobre la presentación​

  • Antes del WPL, se reservará el salón de actos para hacer las pruebas necesarias y garantizar que todo funcione correctamente.

  • David ha mejorado notablemente su expresión oral, realizando pausas adecuadas. Aunque en las enumeraciones aún tiende a ir rápido, ha mejorado hacia el final.

  • Mejorar la coherencia narrativa: se comenzó con el tema del bebé y las verduras; sería más eficaz que el killer opener lo realizara el personaje del anuncio, construyendo así una historia completa.

Feedback sobre el proyecto​

  • En el anuncio, debe mostrarse comida, especialmente alimentos para bebés, con una escena donde no se sabe qué darle al bebé, para conectar con el propósito de la aplicación.

  • La demo se queda corta: debería reflejar claramente las funciones diferenciadoras como la creación de recetas, métricas del bebé, gestión de múltiples perfiles de bebés, y el marketplace.

  • Las cifras deben abreviarse (por ejemplo, "k" para miles y "M" para millones) y la escala de tiempo debería ajustarse a cada dos meses.

  • El vídeo para inversores necesita mayor desarrollo, especialmente en la parte de paquetes de inversión. Los puntos 4 y 5 pueden acortarse para incluir el retorno estimado de la inversión.

  • Las colaboraciones con influencers son una excelente idea, aunque el coste actual es elevado.

  • Sería conveniente que el filtro fuera un bebé (no es prioritario, pero aportaría valor).

  • La funcionalidad de Spoony es atractiva, pero falta claridad: especificar en qué redes sociales se publica, cuántas publicaciones y si se aplica a todas las plataformas o solo a una. Detallarlo en la diapositiva 17 de la segunda presentación.

  • Incluir los sorteos dentro del plan de marketing.

Grupo 7 - Map Your World​

Semana 10/02

Feedback relacionado con la presentación​

  • Presentar de forma clara, evitar hablar muy rápido.
  • Plantillas para presentaciones útiles y con motivo: “es un espacio de publicidad gratuito”. Muy importante la estética.
  • Es importante que la presentación sea un soporte para lo que se cuenta: menos texto y más diagramas.
  • Tener en cuenta y cuidado elementos "tensores" en diapositivas (distraen).
  • No dejar mucho espacio en blanco.
  • Eslogan más claro y descriptivo. Además, al ser un texto muy largo no se suele leer y es importante que lo que se diga sea coherente con lo que pone. También marcar en negrita las cosas fundamentales.
  • Empatizar con el público, evitar decir la mejor aplicación para …
  • Evitar salir con un papel a presentar.
  • Tablas comparativas en la presentación (competidores).
  • Se pueden hacer varias y dividirlas por secciones.
  • No mezclar equipos y roles.

Feedback relacionado con el desarrollo del proyecto​

  • Tener un logo del proyecto.
  • Ahora mismo estamos en fase de análisis, por lo que no hace falta que se den las soluciones de implementación
  • Público objetivo: tenerlos muy claros y diferenciados (si son conjuntos o disjuntos, que elementos tienen que tener…)
  • Casos de usos: especificarlos por tipo de usuario

Semana 17/02

Feedback relacionado con la presentación​

  • No hacer referencias a presentaciones anteriores, tratar las presentaciones de forma autocontenida.
  • Demasiados competidores, hay que indicar CÓMO se han buscado esos competidores
  • Ordenar las tablas de competidores
  • Poner los usuarios pilotos
  • Nuevamente, si algo no se pone en la presentación, no se ha hecho
  • El coste se pone después de explicar las funcionalidades y despertar el interés de los espectadores.
  • Dar más importancia a la privacidad. Es importante eliminar los miedos de los clientes.
  • Poner leyendas si se ponen iconos (o no poner iconos).

Feedback relacionado con el desarrollo del proyecto​

  • Hay que explicar bien el solapamiento entre competidores (puede ser que uno no sea competidor)
  • En el caso de los usuarios objetivos, si uno de ellos no es relevante o no supone funcionalidades o perfiles específicos es mejor quitarlos.

Semana 24/02

Feedback relacionado con la presentación​

  • Intencionalmente en blanco

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 03/03

Feedback relacionado con la presentación​

  • No hablar de puntos que no tocan en la presentación.
  • No hablar tan ligero
  • Organizar la información en tablas, evitar usar llaves porque dificultan el entendimiento de la información.
  • Utilizar terminología del tema que estamos tratando, por ejemplo capex en el tema de costes.
  • Homogeneizar la distribución de los contenidos.
  • No poner información que no dé tiempo a digerir.
  • Mucho texto en la presentación, utilizar más metáforas visuales.
  • Usar porcentajes para representar progresos de cualquier tipo.
  • Última transparencia incluir landing page siempre.

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 10/03

Feedback relacionado con la presentación​

  • Hacer una demo en directo es arriesgado; mejor usar un video grabado.

  • La demo de escritorio no aporta valor, ya que la aplicación está enfocada a dispositivos móviles.

  • Los enlaces a la demo deben ubicarse al final de la presentación.

  • Se debe evitar dar respuestas vagas al explicar los problemas enfrentados

Feedback relacionado con el desarrollo del proyecto​

  • Es necesario actualizar el registro de riesgos; no se pudo hacer a tiempo debido a múltiples problemas.

  • Faltan métricas de productividad consolidadas, y se deberían mostrar de manera clara para entender cómo se calculan las evaluaciones.

  • La planificación del Sprint 2 se entendería mejor con un diagrama de Gantt.

  • Buen uso de la IA exponiendo casos reales.

Semana 17/02

Feedback relacionado con la presentación​

  • La introducción carece de energía, lo que afecta la credibilidad del personaje y la historia presentada. Se recomienda mejorar la entrega para captar mejor la atención del público.
  • Durante la demo, se realizaron demasiados logins, lo que ralentizó la presentación. Se sugiere optimizar este proceso para que fluya mejor.
  • El tiempo fue demasiado ajustado. Es importante gestionar mejor los tiempos para evitar prisas al final y garantizar que toda la información clave se presente con claridad.

Feedback relacionado con el desarrollo del proyecto​

  • Las soluciones presentadas deben ser efectivas y aplicadas correctamente, no solo propuestas teóricas.
  • La tabla de competidores y su análisis no encajan bien con el resto de la presentación. Se recomienda replantear su inclusión o presentarla de una forma más integrada con el discurso general.
  • A la hora de hablar sobre el equipo, es importante no mencionar fotos ni nombres, manteniendo un enfoque más profesional y general.

Semana 24/03

Feedback relacionado con la presentación​

  • El presentador lo hizo muy bien.
  • El killer opener puede mejorar significativamente. Se recomienda añadir originalidad, por ejemplo, entrando en clase utilizando la propia aplicación.
  • Hay diapositivas en las que se pierde el número de transparencia; es importante mantenerlo visible para facilitar el seguimiento.
  • No es necesario nombrar a cada miembro del equipo individualmente. Se puede incluir un resumen con fotos sin mencionarlos uno por uno.
  • La diapositiva del círculo con números no se entiende bien; hay que mejorar su diseño y claridad.
  • La retrospectiva en círculo se lee en sentido antihorario, lo cual no es correcto; es importante corregirlo.
  • La diapositiva de costes con los círculos es confusa, hay que revisarla para que los datos sean más claros y coherentes.

Feedback relacionado con el desarrollo del proyecto​

  • Buen producto, pero el modelo de negocio necesita mejoras.
  • La gráfica de costes no encaja con los números y datos mostrados. Se necesita un crecimiento exponencial, pero con el presupuesto actual, las cifras no cuadran. Antes de seguir desarrollando la aplicación, deben asegurarse de que las cuentas sean viables.
  • El storyboard debe ser independiente y bien diferenciado, aunque se entienda la intención de unirlos. En la versión para inversores, sería útil resumirlo e incluir datos numéricos atractivos.
  • La idea de los mapas colaborativos tiene mucho potencial y debería explotarse más. Actualmente, si los usuarios no caminan, no usan la aplicación; es clave pensar en funcionalidades que fomenten su uso en equipo.
  • En la sección de pricing, los precios aparecen en la demo, pero no en una diapositiva específica. Es importante incluirlos en una transparencia aparte.
  • La escala en la gráfica de rendimiento y esfuerzo debe mejorar; es preferible quitar los nombres y centrarse en los ejes X e Y.
  • La aproximación de precios debe ser más realista. Indicaron valores de 2 a 10 €, pero la estimación de 100 € parece poco fundamentada.
  • Se debe considerar más el punto de vista de los usuarios para mejorar la propuesta de valor. Innovar no siempre es la mejor opción si se pierde claridad en la información. La diapositiva Traspa 10 no deja claro qué es lo más importante.
  • En la parte de métricas y análisis, no basta con numerarlas; es clave identificar buenas y malas prácticas y extraer conclusiones.
  • Las tareas y responsabilidades deben estar bien definidas y no improvisadas.
  • Actualmente, el proyecto lleva un retraso considerable; es fundamental mejorar la planificación.

Semana 31/03

Feedback relacionado con la presentación​

  • Presentación muy sólida, con un inicio efectivo y bien enlazado con el anuncio, lo cual generó buen impacto.
  • En el vídeo, se podría considerar grabar caminando en lugar de quedarse en un solo sitio para hacerlo más dinámico. También sería útil especificar claramente cuáles son las funcionalidades premium.
  • Durante la demo, sería recomendable mostrar iconos que indiquen quién está utilizando cada parte del sistema
  • La demo podría beneficiarse de un poco más de zoom y un ritmo más pausado para facilitar la comprensión. También es importante revisar el uso de texto tipo lorem ipsum.
  • El storyboard para inversores está bien planteado e incluye algunas opciones de inversión, aunque sería útil acotar mejor esas opciones.
  • La gráfica de la diapositiva 32 sobre la evolución de métricas de predicción está muy bien, pero sería conveniente que las líneas fueran rayadas o discontinuas para mayor claridad.
  • En la diapositiva 36, la evolución de la calidad del código está bien mostrada; convendría indicar de forma más precisa cómo ha sido esa evolución.
  • En la diapositiva 40 hay iconos que no se cargan correctamente; revisar las imágenes para que aparezcan

Feedback relacionado con el desarrollo del proyecto​

  • La idea de establecer alianzas con usuarios como estrategia de marketing y generación de ingresos es interesante y tiene potencial.
  • El plan de precios dirigido a empresas está bien pensado e integrado en el proyecto.
  • La proyección financiera necesita una revisión, especialmente en el eje X del gráfico, que actualmente no está alineado correctamente a izquierda y derecha.
  • Sería bueno mostrar con mayor claridad el avance exacto de las tareas del equipo.

Semana 07/04

Feedback sobre la presentación​

  • Excelente energía al presentar, aunque el ritmo acelerado hace que el nombre se entienda como “Marioworld”.
  • El vídeo para usuario transmite muy bien el propósito de la app, mostrando a la persona en movimiento.
  • Se recomienda que los datos utilizados en el vídeo del inversor estén incluidos ahí mismo y no repetidos en la presentación.
  • El testing fue exhaustivo, pero sería necesario incluir los bugs detectados en la presentación de forma detallada.

Feedback sobre el proyecto​

  • El vídeo de inversores está a contraluz; conviene mejorar la iluminación y claridad del mismo.
  • Es importante incluir cifras que respalden el potencial de negocio de MapYourWorld, tanto actuales como proyectadas.
  • Aportar datos combinados con las acciones de marketing planeadas fortalecerá la estrategia de cara a inversores.
  • Deben contemplar el impacto legal a nivel regional y nacional, y considerar posibles restricciones legales.

Semana 21/04

Feedback sobre la presentación​

  • La presentación no incluyó un killer opener, lo que dificultó captar la atención inicial de la audiencia. Esto, sumado a la ausencia de un elevator pitch claro, provocó una falta de coherencia y de hilo argumental.

  • El audio presentó problemas de eco, lo cual afectó la comprensión.

  • Aunque el anuncio para captar clientes estuvo bien planteado, la demo fue demasiado acelerada. La música de fondo, en lugar de aportar, resultó más una distracción.

Feedback sobre el proyecto​

  • En la proyección de beneficios, se observa una disminución de gastos en la semana 30 que luego vuelve a subir. Es importante que el equipo tenga claridad sobre estas variaciones y pueda explicarlas con precisión.

  • En la tabla de competidores, se deben destacar de forma más evidente los elementos que diferencian a MapYourWorld del resto.

  • Fue muy valorada la estrategia de publicaciones según el tipo de usuario y objetivo.

  • El cronograma de pre-lanzamiento, lanzamiento y post-lanzamiento está bien estructurado, pero faltó concretar fechas específicas para las publicaciones. Aunque el equipo tenía esta información preparada, no la mostraron durante la presentación.

  • Es necesario definir los objetivos concretos que se buscan con las publicaciones (por ejemplo, métricas de impresiones, engagement o conversiones).

  • Hace falta detallar cuánto se va a invertir en cada red social, el coste por usuario, coste por instalación, y realizar experimentos que permitan estimar ingresos esperados y tipos de anuncios a utilizar.

  • El branding ha sido bien recibido. Sin embargo, se necesita definir con precisión el uso tipográfico y los estilos visuales del logo, como la sombra o la fuente exacta, ya que actualmente no parece corresponder a una fuente estándar.

Grupo 9 - Caronte​

Semana 10/02

Feedback relacionado con la presentación​

  • Intencionalmente en blanco

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 17/02

Feedback relacionado con la presentación​

  • Hablar primero de nosotros (mayoritariamente de forma positiva) y luego las comparaciones con los demás.

Feedback relacionado con el desarrollo del proyecto​

  • No hay que criticar a la competencia, tan solo diferenciarse.

Semana 24/02

Feedback relacionado con la presentación​

  • Intencionalmente en blanco

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 03/03

Feedback relacionado con la presentación​

  • No han contado qué ofrecen antes de hablar de la competencia.
  • Crear un clima donde se normalice el tema del que se habla.
  • Si vas a cobrar una cuota constante, tienes que ofrecer un servicio constante.
  • Llevar incluidos los impuestos. Hablar de los gastos en bruto.

Feedback relacionado con el desarrollo del proyecto​

  • Costes insuficientes. Poner costes, ingresos y gastos. Hay que ser más conservadores en los cálculos.

Semana 10/03

Feedback relacionado con la presentación​

  • La presentación tiene un diseño muy cuidado. Se recomienda que las barras de progreso indiquen claramente hasta dónde llega el porcentaje.

  • En la gráfica del equipo de trabajo:

    • Pasar más rápido por esta diapositiva.
    • En lugar de usar bolas con números, mostrar imágenes de las personas y sus responsabilidades.

  • En la diapositiva 14:

    • Los decimales en el número de horas no aportan valor.
    • Dividir la información por sprint con una línea.Las horas totales no son tan relevantes; es mejor mostrar la media de horas.

Feedback relacionado con el desarrollo del proyecto​

  • En la diapositiva 7, la transparencia refleja datos mes a mes, pero no de manera acumulativa. Se debería mostrar de forma acumulativa e incluir pérdidas y ganancias.

  • Anticipar el problema de gestión de pagos desde el inicio, ya que incluso el equipo cree que puede ser un inconveniente. La PoC (prueba de concepto) debería haberse realizado en el Sprint 1.

Semana 17/03

Feedback relacionado con la presentación​

  • La presentación debe ser autocontenida, incluyendo pequeñas explicaciones que permitan entenderla sin necesidad de aclaraciones adicionales.
  • Es recomendable anunciar previamente el propósito del video, explicando que se debe a las pruebas realizadas con usuarios piloto, sin desvelar sus comentarios antes de tiempo.
  • El "killer opener" fue efectivo en concepto, pero su ejecución podría mejorarse. Sería útil incluir un elemento visual que lo haga más motivador.
  • La diapositiva 7 está muy bien lograda, con gran cantidad de información en poco espacio y un uso correcto de colores.
  • La diapositiva 30 también está bien, pero se sugiere incluir elementos en "In Progress" e "In Review", además de visualizar las "issues" y su estado, identificando cuánto tiempo permanecen en el backlog sin moverse.
  • Es recomendable incluir un video en la demo para explicar el proceso, ya que en presentaciones en línea pueden surgir más fallos.
  • Incluir una medición clara sobre el impacto y la efectividad de las soluciones aplicadas.

Feedback relacionado con el desarrollo del proyecto​

  • El storyboard está bien planteado y tiene un enfoque emotivo. Sin embargo, cuando se convierta en un anuncio, es recomendable reformularlo para incluir información sobre precios, que actualmente se echa en falta.
  • Aspectos legales (GDPR): Es necesario asegurarse de que se cumple con la normativa GDPR, incluir un mecanismo para borrar datos de usuarios, tener un plan de acción en caso de recibir una denuncia relacionada con el GDPR y no automatizar procesos sin evaluar las implicaciones legales y éticas, pero se recomienda añadir un botón o formulario para gestionar estos aspectos.
  • Se han destinado demasiadas horas para una sola semana dentro del sprint. Sería conveniente reducir el alcance o replantear la estrategia.
  • Es fundamental mejorar la planificación teniendo en cuenta los periodos de exámenes.
  • Es importante realizar mediciones periódicas para evaluar si las soluciones implementadas están funcionando correctamente.
  • Se recomienda incluir información sobre ingresos y gastos en lugar de ingresos y pérdidas.
  • Reflejar el rendimiento del equipo a lo largo del tiempo, ya que es un aspecto obligatorio en la evaluación.
  • Aprovechar mejor la tecnología disponible para optimizar procesos.
  • El uso de Codacy ha sido correcto, y sería útil incluir una gráfica de evolución.

Semana 24/03

Feedback relacionado con la presentación​

  • Muy buen trabajo y bien presentado.
  • Han mejorado el inicio con elementos visuales, y el elevator pitch fue muy correcto.
  • Aun así, el killer opener en comparación con los storyboards podría mejorarse. Sería útil enfocarse más en los storyboards para lograr un mayor impacto.
  • El orden de la presentación podría ajustarse: después del elevator pitch, no es recomendable mostrar la demo directamente. Sería mejor remarcar primero las diferencias con la competencia.
  • La demo no se visualizó bien; es importante hacer zoom para que se vea con claridad. No obstante, el uso de los cuatro cuadrantes y las gráficas burnup y burndown fue muy bueno.

Feedback relacionado con el desarrollo del proyecto​

  • Se nota que han dedicado muchas horas al proyecto.
  • Sería recomendable reducir el alcance o gestionar mejor la carga de trabajo, especialmente para quienes han invertido más tiempo.
  • La presentación de la parte de Codacy fue muy buena.
  • Incluir métricas de Codacy y su evolución en una misma diapositiva facilitaría su análisis.
  • Como sugerencia, podrían explorar el nuevo uso de Copilot para revisar pull requests.
  • Han utilizado Claudete en el Customer Agreement para detectar cláusulas abusivas, pero no lo han mencionado en la presentación; sería bueno resaltarlo.
  • Habría sido útil mostrar el feedback de los usuarios piloto, explicando cómo lo priorizan y resuelven.

Semana 31/03

Feedback relacionado con la presentación​

  • Vídeo: En general, muy bien realizado. Sin embargo, podría resultar un poco largo. Una posible mejora sería agrupar varios mensajes sobre pantalla negra en una sola secuencia para hacerlo más dinámico.
  • Presentador (Daniel): Excelente desempeño en la presentación, comunica con claridad y confianza.
  • Elevator pitch: Muy bien trabajado y refinado. Transmite con claridad el propósito del proyecto.
  • Storyboard para inversores: Está bien planteado, pero sería conveniente añadir distintas opciones de inversión para hacerlo más completo.
  • Monetización: Sería recomendable aplicar una paleta de colores coherente en la diapositiva de monetización (especialmente en las secciones de CapEx y OpEx) para facilitar la comprensión visual.
  • Gráfica de horas trabajadas: Sería útil solapar las horas semanales con la media de horas de cada persona para visualizar desviaciones. También es algo que podríamos aplicar en nuestro propio trabajo.
  • Lecciones aprendidas: Revisar la redacción de esta sección, en particular la parte que menciona el "aumento de la deuda técnica", para que sea más clara y reflexiva
  • Usuarios piloto: Añadir una sección específica con el feedback recibido, incluyendo también los comentarios que se decidió no tener en cuenta.

Feedback relacionado con el desarrollo del proyecto​

  • Testing: Considerar si sería útil incorporar pruebas de interfaz con Selenium para mejorar la calidad del producto.
  • Plan de tracción: Es importante comenzar a definir un plan de captación y crecimiento de usuarios. Esto es algo que también deberíamos ir considerando nosotros.

Semana 07/04

Feedback sobre la presentación​

  • Excelente gestión del tiempo. Sin embargo, la demo fue demasiado rápida; no es necesario mostrar todos los casos de uso.
  • Quizás hubo demasiado uso de zoom en la demo. Recordar que también se presenta ante profesores, no solo usuarios.
  • Las gráficas de rendimiento, especialmente las de horas y burn-up, son difíciles de interpretar. Se recomienda rediseñarlas para que transmitan el mensaje de forma más clara.

Feedback sobre el proyecto​

  • Los anuncios fueron espectaculares, salvo el de empresa, que perdió fuerza. Por ejemplo, en el caso de la floristería, ni siquiera apareció una maceta.
  • El anuncio para inversores está mucho más trabajado y ha mejorado notablemente.

Semana 21/04

Feedback sobre la presentación​

  • El mensaje inicial con el collage de imágenes resulta recargado y poco serio, contrastando con el tono del vídeo posterior. Se recomienda reconsiderar el orden de los elementos.

  • El eslogan carece de fuerza emocional en comparación con el vídeo. Sería más efectivo presentarlo después del vídeo.

  • Las diapositivas relativas a "moral" y "horas invertidas" no son necesarias en la presentación.

  • En el vídeo para inversores, el audio tiene mala calidad y la introducción no es coherente con el resto del contenido.

Feedback sobre el proyecto​

  • En la diapositiva de monetización (CAPEX y OPEX), se deben explicar mejor los conceptos de escenario pesimista y optimista. Este error también aparece en el vídeo para inversores.

  • En la presentación de inversión, es importante aclarar qué porcentaje de la empresa se ofrece a cambio de las acciones vendidas.

  • Revisar los perfiles de protopersonas: por ejemplo, no debería figurar como estado civil "trabajando" y "jubilada" tampoco tiene sentido en este contexto.

  • Excelente la idea del concurso interno de anuncios.

  • La integración de IA para la validación de esquelas es un elemento clave, ya que automatiza un proceso que de otro modo requeriría contratación.

  • Buen trabajo en el número de publicaciones alcanzadas.

Grupo 10 - Go 4 Surprise​

Semana 10/02

Feedback relacionado con la presentación​

  • Intencionalmente en blanco

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 17/02

Feedback relacionado con la presentación​

  • Hacer mockups que cuenten una historia, no hacer mockups de informáticos para informáticos.

Feedback relacionado con el desarrollo del proyecto​

  • Demasiadas cosas

Semana 24/02

Feedback relacionado con la presentación​

  • Número de página muy pequeño. Barra de progreso que pasa desapercibido.
  • Cuidado con el cálculo de los costes de los empleados, principalmente con los costes sociales.
  • Especificar qué es exactamente cada número que aparezca en la presentación.

Feedback relacionado con el desarrollo del proyecto​

  • Tener cuidado con los riesgos y definir bien los planes de contingencia.

Semana 03/03

Feedback relacionado con la presentación​

  • No han seguido la estructura de manera correcta. No han intentado un inicio efectivo (que tiene que aparecer en cada presentación). Saber captar la atención. No tiene por qué empezar con un índice.
  • Tras el inicio efectivo incluir el Elevator Pitch (explicar la idea del proyecto en una frase, y por qué nosotros).
  • Mostrar algunas referencias de los trabajadores del proyecto.
  • Mostrar los costes de forma más liviana, sin saturar, y preferiblemente que sea autoexplicativo.
  • No mencionar el tema de la captación de los usuarios piloto a estas alturas, preferiblemente hablar sobre el proyecto en desarrollo en cuestión. Hablar de la gestión de los usuarios piloto en lugar de las protopersonas (cuántos usuarios pilotos tenemos, cómo vamos a gestionar el feedback, etc).
  • No hablar de riesgos, más bien hablar de problemas (se pueden relacionar con los riesgos: ver cómo han evolucionado)
  • Equiparar lo máximo posible el número de de horas invertidas por cada miembro del equipo
  • Un caso de uso core NO es el inicio de sesión (no tiene sentido empezar por esa funcionalidad), tiene que estar orientado a alguna funcionalidad como tal del sistema.
  • Letra pequeña en la presentación de la landing page (haberle dado zoom una mijita)

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 10/03

Feedback relacionado con la presentación​

  • Excelente presentación por parte del ponente, con un punto extra por entusiasmo en el killer opener. Sin embargo, cuidado al lanzar preguntas al público asumiendo que la respuesta será afirmativa.

  • Mencionar alcohol en la presentación puede ser arriesgado dependiendo del tipo de público.

  • La transición entre las diapositivas 6 y 7 podría ser más fluida; se recomienda presentarlas juntas. Además, hay inconsistencias en las escalas de las gráficas (una en semanas y otra en meses).

  • Buena estrategia al definir los roles del equipo (mayoría full-stack). Se recomienda homogeneizar el formato de las fotos.

  • Se debe mejorar la sincronización entre el video y el presentador, así como mayor zoom en el video.

  • Para el análisis del sprint, sería mejor dividir la presentación en tres diapositivas:

    • Lo que ha funcionado bien
    • Lo que ha fallado
    • Lo que se debe mejorar

  • Además, se recomienda adelantar los problemas en la presentación en lugar de mencionarlos más adelante.

Feedback relacionado con el desarrollo del proyecto​

  • Es preferible hablar de estimación esperada de ingresos en lugar de estimación media.

  • En la demo, la parte de registro y login no es necesaria; lo más importante es mostrar la funcionalidad de los casos de uso core.

  • Diagramas de Gantt bien utilizados para visualizar el desarrollo de tareas.

  • Se ha echado en falta información sobre cómo se ha tenido en cuenta el feedback de los usuarios piloto.

Semana 17/03

Feedback relacionado con la presentación​

  • La diapositiva sobre el rendimiento del equipo está muy bien trabajada.
  • La introducción debe organizarse mejor: actualmente se explica quiénes son sin aclarar qué hacen.
  • Se recomienda orientar el discurso inicial en torno a una palabra clave que refuerce el mensaje central.
  • No hacer preguntas abiertas al inicio; en su lugar, plantear una situación clara con la que todos puedan identificarse.
  • En la diapositiva 40 sobre la planificación de usuarios piloto, las letras con fondo rojo dificultan la lectura. Se recomienda cambiar los colores para mejorar la visibilidad.
  • En general, se debe prestar más atención a la combinación de colores de fondo para garantizar una buena legibilidad.
  • En la demo, hay un momento en el que el ritmo se vuelve demasiado rápido, lo que dificulta la comprensión. Es importante mantener un ritmo constante y claro.
  • El términos generales, el presentador lo hizo muy bien en todo momento.

Feedback relacionado con el desarrollo del proyecto​

  • La presentación explica quiénes son, pero no deja claro qué hacen exactamente. Es importante organizar mejor la estructura para que el mensaje sea más claro.
  • El concepto de "experiencia" es clave para el proyecto, pero se menciona muy poco. Se recomienda reforzar su presencia en el discurso.
  • Se sugiere mantener el factor sorpresa como un punto fuerte, pero de manera contenida y bien dosificada. En el inicio de la presentación, se puede potenciar este aspecto de forma efectiva.
  • Es importante transmitir que el equipo es una inversión, no un coste.
  • La fórmula de ingresos es complicada y puede generar confusión; en su lugar, es mejor explicar los factores clave sin centrarse demasiado en los cálculos.
  • La licencia del software permite ver el código fuente, pero en este caso, mostrarlo no tiene sentido. Se recomienda no incluirlo en la presentación.
  • Se ha implementado una estrategia para evitar la reventa de entradas asignando nombres y entregándolas 24 horas antes del evento.
  • El storyboard es sólido, pero se recomienda eliminar la "magia" del momento en que aparece la marca Go4Surprise, haciéndolo más natural y menos repentino.
  • Lo ideal es ir directamente a los casos de uso principales sin desviarse en explicaciones innecesarias.
  • En retrospectiva, la falta de comunicación dentro del equipo se ha reflejado en la dificultad para informar sobre el avance de tareas.

Semana 24/03

Feedback relacionado con la presentación​

  • Buen ritmo y argumentación en general, con una estructura clara y bien organizada.
  • Inicio muy efectivo y bien planteado.
  • Es importante evitar términos demasiado coloquiales para mantener un tono profesional.
  • El presentador lo hizo muy bien, pero debe intentar mirar a todo el público, no solo a los profesores. Se recomienda mirar a las cuatro esquinas de la sala para abarcar a todos los oyentes.
  • La presentación tuvo un buen hilo argumental, con un formato tipo pregunta-respuesta bien hilado.
  • Se recomienda personalizar más la presentación, haciendo que parezca que los propios ponentes usan realmente la aplicación.
  • Buscar un eslogan y una mascota ayudaría a reforzar la identidad del proyecto, algo que todos los grupos deberían considerar.

Feedback relacionado con el desarrollo del proyecto​

  • Los storyboards están muy bien planteados y desarrollados.
  • Como idea, podrían representar en los storyboards dos tipos de usuarios: uno deprimido y otro aburrido, y cómo la aplicación les aporta valor.
  • En lugar de excluir a los menores de 18 años, sería mejor incluir sorpresas o contenido específico para ellos.
  • No se debe minimizar los problemas que han surgido. Es importante explicar qué ha salido mal y, sobre todo, cómo se ha solucionado (problema = solución).
  • La evolución del rendimiento del equipo debe mostrarse de manera más clara. Para ello, se recomienda unir los puntos entre los distintos sprints en la gráfica de rendimiento.
  • El SLA (Acuerdo de Nivel de Servicio) no apareció en la presentación, pero se tiene previsto incluirlo pronto; sería bueno destacarlo en futuras presentaciones.

Semana 31/03

Feedback relacionado con la presentación​

  • Muy buen trabajo en general, con una presentación clara y bien estructurada.
  • El presentador lo hizo muy bien y el contenido estuvo bien explicado.
  • El anuncio fue de gran calidad, aunque quizás un poco largo. Además, el móvil que aparece en el vídeo se ve demasiado pequeño, por lo que convendría mostrarlo en pantalla de forma más destacada.
  • Las diapositivas 27 y 28, que presentan problemas y soluciones, se beneficiarían de una mejor organización. En lugar de listar todos los problemas y luego todas las soluciones, sería más claro presentar cada problema junto con su solución correspondiente.
  • En la diapositiva sobre inteligencia artificial, el contenido no se alcanza a leer. Habría que mejorar la legibilidad o simplificar el texto.
  • La comparativa de rendimiento del equipo usando colores rojo y verde es una buena idea visual. Sin embargo, falta una referencia que indique cómo se comparan esos datos respecto a la semana anterior o a la media de horas trabajadas.
  • Las fórmulas mostradas en una de las diapositivas deben eliminarse, ya que no aportan claridad al público general.

Feedback relacionado con el desarrollo del proyecto​

  • Muy buena idea utilizar el slogan "la vida misma es una sorpresa" como mantra del proyecto; es pegadizo, coherente y ha sido bien transmitido.
  • En la demo, es mejor no mostrar elementos como la opción de "contraseña olvidada", ya que no aporta valor en ese contexto. Sería importante incluir la estimación del número de usuarios esperados, diferenciando entre un escenario optimista y uno pesimista.

Semana 07/04

Feedback sobre la presentación​

  • El killer opener ya no genera tanto impacto como antes; sería recomendable innovar y buscar uno que encaje mejor con el WPL.
  • La sección de roles del equipo podría unificarse en una sola diapositiva, en lugar de dividirla entre varias personas.
  • El presentador no entró en detalle al explicar el primer problema del proyecto; sería útil profundizar en las causas para llegar a la raíz del mismo.
  • Buena explicación del resto de problemas, aunque da la sensación de que actualmente no enfrentan ninguno. Sería útil clarificar si realmente es así o simplemente no se abordaron.
  • La matriz de rendimiento del equipo fue muy clara y está bien explicada.

Feedback sobre el proyecto​

  • El vídeo dirigido a inversores parece más un anuncio comercial. Se recomienda cambiar el título y desarrollar un storyboard específico para el enfoque de inversión.
  • El anuncio para cliente es un poco largo; convendría hacerlo más conciso.
  • El anuncio comercial o para inversores debe ser autocontenido y ofrecer suficiente contexto para ser entendido por sí solo.
  • En las demos, aunque el contenido es bueno, se echa en falta un mayor enfoque (zoom) en ciertos momentos clave. Además, sería interesante incluir al personaje "Sorpresín" explicando elementos de la demo.
  • No se ha explicado de forma clara la diferenciación respecto a la competencia, especialmente sobre si los demás también ofrecen experiencias sorpresa.
  • El test realizado con Locust se ha hecho en local, no en producción; hay que tener cuidado con este tipo de pruebas.

Semana 21/04

Feedback sobre la presentación​

  • Presentación muy efectiva, destacando especialmente el killer opener y el anuncio con "Sorpresín".

  • Mejorar ligeramente el ritmo del diálogo durante el vídeo de presentación.

  • En el vídeo de demo, sería conveniente mostrar más características del producto.

  • El vídeo dirigido al cliente tiene un buen detalle, pero no requiere una presentación tan extensa.

  • No es necesario incluir una retrospectiva del trabajo en la presentación final.

  • El anuncio para inversores tiene un concepto acertado y es divertido, pero algunos elementos clave se pierden visualmente.

Feedback sobre el proyecto​

  • La diapositiva de mercado objetivo contiene demasiada información; debe simplificarse. A cambio, se puede ampliar la sección de estimación de ingresos.

  • En el WPL, se recomienda incluir solo la estimación esperada y omitir las versiones optimista y pesimista.

  • Explicar más a fondo el modelo de negocio.

  • En la sección de publicidad, explicar cómo se segmentará al público objetivo.

Grupo 11 - Pawtel​

Semana 10/02

Feedback relacionado con la presentación​

  • Intencionalmente en blanco

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 17/02

Feedback relacionado con la presentación​

  • Invierten más tiempo en decir lo que no son que lo que son.
  • Demasiado enfocada la presentación en las partes negativas, esto tiene un impacto negativo en la audiencia.
  • Mucho ruido en la presentación.
  • Mockups muy cutres, no se diferencian de sus competidores
  • Además durante la presentación no les ha dado importancia.
  • Diapositivas que no se leen bien (análisis de riesgos)
  • No usar lenguaje informal (volcao pa la derecha)
  • Todos los datos tienen que tener algún tipo de justificación, sobre todo si son numéricos
  • Datos objetivos, evitar la subjetividad del presentador.
  • Explicar los conceptos que ser presenten y que sean originales y específicos del equipo
  • Habilidades técnicas del equipo, explicar las decisiones del equipo justificandolas con datos.

Feedback relacionado con el desarrollo del proyecto​

  • No le ha quedado claro la idea, la descripción y marca tienen que ser más claras.
  • Ver si un competidor lo es realmente (en las píldoras vienen explicados 3 tipos, clasificarlos ahí)
  • Strikes (tarjetas amarilla y roja)

Semana 24/02

Feedback relacionado con la presentación​

  • En los costes poner un caso intermedio a parte del optimista y el pesimista.

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 03/03

Feedback relacionado con la presentación​

  • No se ve bien el número de página.
  • En la retrospectiva explicar un poco más la parte de qué problemas hemos tenido y cómo los hemos solucionado. Cuantificar la evolución del sprint (Ej: hemos completado un 30% del sprint).
  • La medición del rendimiento está bien, pero las métricas tienen que ir ajustadas al perfil/rol de cada persona. Es interesante incluir métricas negativas, donde el mejor número sea 0.
  • Mostrar la medición individual de cada miembro, incluso con las caras (aunque sea incómodo). Lógicamente, que cada valoración represente la realidad: no inventarla.
  • No rellenar la presentación con dibujos o motivos que no guarden relación con el contenido de la misma o que no sean de la temática.
  • Pensar una forma más creativa de presentar la demo (por ejemplo presentar un caso de uso), que no parezca que sea un mockup.
  • En el tema de los usuarios piloto incluir una agenda.
  • No utilizar anglicismos. Siempre usar palabras españolas.

Feedback relacionado con el desarrollo del proyecto​

  • Intencionalmente en blanco

Semana 10/03

Feedback relacionado con la presentación​

  • El killer opening parece más un anuncio que una forma de atraer a la audiencia, ser más imaginativo y dejar claro que hay un problema a resolver.
  • Evitar hacer la demo en directo para prevenir errores técnicos (pantalla azul de Windows). Es preferible usar un video con zoom.
  • Buena idea incluir un Hall of Fame y Hall of Shame.

Feedback relacionado con el desarrollo del proyecto​

  • La gráfica de usuarios de alojamiento para mascotas carece de información a partir de 2025.

  • La gráfica de costes no puede mantenerse constante durante 24 meses. Aunque los costes de desarrollo sean altos, en producción también aumentan (mantenimiento y despliegue).

  • Se detecta cierta confusión entre OPEX y CAPEX.

  • El modelo de negocio podría ser vulnerable a cookie stuffing, revisar posibles riesgos.

  • Es importante optimizar las llamadas a la API para mejorar la comunicación entre el backend y el frontend.

  • Se recomienda mejorar el sistema CI/CD.

Semana 17/03

Feedback relacionado con la presentación​

  • El presentador ha sido excelente, y el killer opener ha estado muy bien ejecutado. Sin embargo, en algunos momentos habla demasiado rápido, lo que dificulta la comprensión. Se recomienda moderar el ritmo.
  • No es necesario explicar en el video pasos básicos como "se registra, se loggea", ya que son procesos intuitivos para la audiencia.
  • El término mascota debe repetirse con más frecuencia para reforzar su presencia en el discurso.
  • Se debe indicar claramente qué casos de uso se están presentando y cuáles se van a ver a continuación.
  • Es recomendable incluir un email de contacto al final de la presentación para facilitar el seguimiento.

Feedback relacionado con el desarrollo del proyecto​

  • Es fundamental hilar mejor la introducción con la explicación de lo que es el proyecto para que el mensaje sea más fluido y claro.
  • La presentación debe ser autocontenida, asegurando que toda la información necesaria esté incluida sin depender de explicaciones externas.
  • El primer storyboard es muy bueno. Aunque no haya un modelo de precios definido aún, es recomendable explicar este aspecto de todas maneras para dar contexto.
  • Es crucial que el storyboard sea completamente autocontenido.
  • Es importante unificar el análisis del rendimiento del equipo, en lugar de separarlo en backend y frontend.
  • La consistencia en el code style es clave: tener 600 code style issues es demasiado y debe corregirse.
  • En cuanto a la UI, debe estar o completamente perfecta o al menos al 90%, pero no ambas cosas a la vez. Se debe elegir una postura clara sobre su estado.

Semana 24/03

Feedback relacionado con la presentación​

  • Killer opener muy bien logrado, con una buena conexión entre la mascota y el tema.
  • El ritmo de la presentación es demasiado acelerado, lo que dificulta tomar notas y procesar la información. Se recomienda hablar más pausadamente y estructurar mejor las ideas, evitando enumeraciones inconclusas.
  • Es importante hilar mejor el inicio con la demo para lograr mayor coherencia en el discurso.
  • La diapositiva de evolución del rendimiento del equipo resulta abrumadora ("bombardeo de pelotas"); sería útil simplificarla o presentar la información de manera más clara.
  • Al explicar la diapositiva de incidencia y resolución de problemas (III), se ha narrado de abajo arriba, lo que puede dificultar su comprensión.
  • Sería interesante incluir imágenes de la mascota en las fotos para reforzar la identidad visual del proyecto.
  • La palabra clave “mascota” ha sido bien utilizada como eje central del mensaje.

Feedback relacionado con el desarrollo del proyecto​

  • La idea del mediador para resolver conflictos es muy buena y se recomienda implementarla en todos los grupos.
  • Se necesitan más cifras y datos numéricos en el storyboard para inversores.
  • La gráfica de rendimiento del Sprint 2 no está bien centrada y necesita ajustes.
  • La gráfica de costes presenta errores en la parte CAPEX, por lo que debe revisarse.
  • A veces, los números netos no son lo más importante; es clave enfocarse en datos que realmente aporten valor a la toma de decisiones.
  • Es importante definir y mantener los estilos de código en Codacy para mejorar la calidad y coherencia del código.
  • Cuando se utilicen rangos en gráficos o análisis, deben estar correctamente definidos y justificados.
  • El ejemplo utilizado en la demo es demasiado costoso y no representa bien el caso de uso; sería recomendable elegir un ejemplo más realista.

Semana 31/03

Feedback relacionado con la presentación​

  • Se ha notado una mejora en el inicio efectivo, ahora es más directo y enfocado. Aun así, sería conveniente cuidar mejor la elección de palabras para transmitir profesionalismo.
  • Es importante evitar frases como "esto es muy fácil", ya que pueden restar seriedad o dar una impresión equivocada.
  • El inicio efectivo estuvo muy bien conectado con la demo y con el cierre de la presentación. El hilo argumental en general se percibió bien ensayado y estructurado.
  • El impacto legal del proyecto debe estar mejor integrado en el ritmo general de la presentación. La justificación de por qué no se incluyó cierto contenido se sintió forzada y poco natural.

Feedback relacionado con el desarrollo del proyecto​

  • Muy bien las mejoras implementadas a partir del feedback de los usuarios piloto, y además bien integradas en la presentación.
  • El storyboard orientado a los usuarios está muy bien elaborado. El anuncio es de tan buena calidad que se plantea reutilizarlo en futuras ediciones.
  • Sería útil revisar la sección sobre mejoras para el usuario piloto, clarificando si se refieren a una mejora en la experiencia de usuario (UX) o simplemente a una adaptación a sus preferencias.
  • La gráfica de rendimiento del sprint 3 necesita revisión: no es realista que todos los miembros del equipo estén al máximo rendimiento y aún así se obtenga una nota perfecta. Además, los números y leyendas no son legibles.
  • Evitar usar el nombre del archivo directamente como hipervínculo para la demo (por ejemplo, "video.mp4"); es mejor darle un nombre más descriptivo y profesional.

Semana 07/04

Feedback relacionado con la presentación​

  • En los anuncios, mejorar el uso de la IA para mantener una coherencia lingüística, aunque la inclusión de subtítulos es muy acertada para facilitar la comprensión.
  • El inicio está bien conectado, pero se necesita un orden más claro y lineal en las secciones para una presentación más fluida y dinámica.
  • La presentación debe durar entre 14 y 15 minutos, evitando añadir contenido innecesario para alargarla.
  • Mejorar gráficos y tablas: ejes legibles, uso de abreviaciones (“K”) y evitar enlaces poco estéticos.
  • Usar un vocabulario comprensible, evitar tecnicismos en exceso, expresiones condescendientes y mezclar idiomas sin necesidad.
  • Tratar la parte legal de forma natural y no como un añadido forzado que rompa el ritmo narrativo.
  • Gran diferenciación frente a competidores, excelente storyboard y anuncios profesionales reutilizables.

Feedback relacionado con el desarrollo del proyecto​

  • Si todos los usuarios obtienen una puntuación de 10, puede que la métrica no sea útil; se recomienda revisar el sistema de evaluación.
  • Limitar las calificaciones a un máximo de 10 puede indicar problemas en el diseño de la escala.
  • Priorizar el feedback de los usuarios piloto en cada iteración.
  • Los usuarios piloto no deben actuar como beta testers; los errores técnicos deberían haberse detectado y corregido previamente.

Semana 21/04

Feedback sobre la presentación​

  • Hubo graves problemas técnicos que impidieron ver correctamente la demo y los anuncios.

  • La historia inicial no resulta realista ni coherente con el resto del proyecto. El presentador logró compensar parcialmente esto con una buena oratoria.

  • La introducción tiene demasiado texto, a pesar de que la historia era divertida.

  • El volumen del audio estaba excesivamente alto.

Feedback sobre el proyecto​

  • Usar un cursor con forma de pata de perro ayudaría a reforzar la narrativa relacionada con "Koko" y su estancia en el hotel.

  • Implementar un sistema de puntos para evitar el uso fraudulento de la app (puenteo) es una idea acertada.

  • Corregir el uso de “Valencia” por “Valenciano” al referirse a idiomas.

  • En la gráfica de posicionamiento digital, utilizar fechas más cercanas entre sí. Reflejar también la estacionalidad del servicio.

  • En cuanto al uso de IA, especificar qué herramientas de inteligencia artificial se han utilizado y mostrarlas explícitamente en la presentación.